I've just run accross a behavior for Service pack 3 for Exchange 2007 that is very different than the expected behavior when you run the /PrepareAD switch. To sum up, /PrepareAD does run successfully and reports that everything went well, but it does not update the schema. The "rangeUpper" value of "ms-Exch-Schema-Version-Pt" stays at 14622 instead of updating to 14625. I've double checked the documentation (http://technet.microsoft.com/en-us/library/bb125224(v=exchg.80).aspx) and it does state in the note under step 2 (/PrepareSchema) that "You can skip this step and prepare the schema as part of Step 3." Step 3 being the /PrepareAD switch. The doc also states that you can skip /PrepareLegacyExchangePermissions as well, if your going to run /PreareAD. All other Exchange 2007 service packs that I have installed update the schema as part of the /PrepareAD switch, in line with what is stated in the documentation. What I found: /PrepareAD creates a Powershell script in the ExchangeSetuplogs directory called "Install-ExchangeOrganization-"Date"-"Time".ps1". Looking at the top of the script created by an Exchange SP2 update, you can see that "$RolePrepareSchema = $True". If you look at the script created by Exchange SP3, you see that "$RolePrepareSchema = $False". So it looks as if the SP3 setup creates a script that doesn't update the schema, which is weird since all documentation and previous service pack behavior says it should. These scripts are auto-generated by the setup program, so I don't know why it changed in Exchange SP3. My environment: Domain is mixed 2003 - 2008R2 (middle of a domain upgrade) Schema Master, and all other FSMO roles are on 2008R2 domain controllers. Exchange server 2007 SP2 rollup 5, upgrading to SP3 rollup 6 "rangeUpper" value of "ms-Exch-Schema-Version-Pt" prior to running /PrepareAD "14622" (Exchange schema version) "objectVersion" value of "cn=schema,cn=configuration,dc=mydomain" "47" (AD schema version) Not sure if the mixed mode of my domain caused the setup file to not flip "$RolePrepareSchema" to True, but I also haven't run across any documentation that states is would, or that you shouldn't update the schema in mixed mode. Interestingly Exchange 2010 RTM's "rangeUpper" value is "14622", so you cannot run /PrepareSchema in an Active Directory that has already been extended by Exchange 2007 SP3 /PrepareSchema, since it will fail the organizational checks. You have to use Exchange 2010 SP1. (see http://social.technet.microsoft.com/wiki/contents/articles/2772.exchange-schema-versions-common-questions-answers.aspx) Makes one wonder if the SP3 /PrepareAD behavior is built in to prevent this issue. Does anyone know of any reason not to force the schema update by running setup.com /PrepareSchema, given the situation above? I've run it in my lab environment, and have not seen any ill effects. However, the lab has fewer servers, and types of servers, than my production environment, and I'm guessing that there must be a good reason why the service pack 3 /PrepareAD didn't actually run the /PrepareSchema operations.

Hi there, Based on my research, it is a known issue and it is expected to be fixed in the next update. As a workaround: For new SP2 to SP3 upgrade, change rangeUpper of ms-Exch-Schema-Version-Pt to number to 14621 prior to upgrading. This works in our local lab. Please make a full backup before you try. For server that already has SP3 installed, you might need to reinstall it. Hope it is helpful. Fiona Liao TechNet Community Support

Hi Fiona, Thanks for the reply. I understand your saying that I can get /PrepareAD to do all its supposed to by changing the ms-Exch-Schema-Version-Pt to number to 14621. This would invoke the missing "$RolePrepareSchema = $True" and "$RolePrepareLegacyExchangePermissions = $True" in the powershell script. (I noticed that "$RolePrepareLegacyExchangePermissions" was also not run after my original post) Since SP3 /PrepareAD has already been run, and only missed the two operations above, I'm thinking that running /PrepareSchema would take care of that, as that command invokes the /PrepareLegacyExchangePermissions as well. This seems a simpler workaround since SP3 has not been installed on the Exchange server yet. This did work in my lab. What do you think? Also, any chance the research you have on this being a "known issue" is available to the public? I'd love to see it, as my main concern is that Microsoft configured the setup file to purposefully omit the /PrepareLegacyExchangePermissions and /PrepareShema due to some issue it sees in my environment, and I'm going to break something by forcing those options to run. Thanks again.

I'm marking the post from Fiona as the answer, since that the only way you'd get the /PrepareAD option to work the way it should on the first try. However, I'm sure that running /PrepareSchema option will finish the AD preparation that /PrepareAD missed. I've checked this by comparing the variable options in SP2's powershell script against SP3's powershell script. I'm thinking that if /PrepareSchema runs without a problem, then it probably is an issue with the SP3 setup. I would have still liked to have seen something from MS on that though. If anybody does have an official link that describes this behavior as a "known issue", please post it in this thread.

Hi Rexif, Thanks for your update. I have already involved a next level engineer in this thread, will keep you posted if there is any update. Fiona Liao TechNet Community Support

Hi Fiona, Thanks for doing that. Looking forward to seeing what you find.

There is no direct article about the issue , closest one is here http://support.microsoft.com/kb/2457729 The issue reported in the KB is due to Schema upgrade mismatch.

Sureshbd-MSFT, Thanks for the post. Makes the argument for running the /PrepareSchema for this issue even stronger.